One thing I found that is not right: I am setting the doubleClick action handler in code, but I forgot to also set the control's target property. Still, when I run the code in the debugger, the action handler gets called even without having assigned the target. So I wonder if that might be the cause of the issue. But if the responder chain was temporarily changed so that the action handler would get called on an object that doesn't implement the action, then I should get an exception about the missing selector (which is pathCellDoubleClicked: in my case), right? But that's not the case as far as I can tell, so I guess the unset target is not the cause here. Or am I wrong?

Just to add some clarification: Apps that run their helper tools via NSTask seem not be affected. At least my app Find Any File remains able to launch its "searchfs" helper this way, which in turn searches entire volumes, once the main app has gotten FDA, even in 11.4. I suspect that the issue is only with helpers that get run outside of the main app's runtime, e.g. as launchd service, Login Item etc. This change was apparently implemented to deal with CVE-2021-30713: (see https://mjtsai.com/blog/2021/06/01/macos-11-4-breaks-full-disk-access-for-helper-tools/#comment-3465367). But in a wrong way: Instead of making sure that embedded helpers are tested to belong to the main app, i.e. have the same codesign Team ID, it simply denies them FDA altogether if they're launched not directly by the main app, it seems. Looks like a hasty fix that was not well thought through. And bug reports about it then being ignored as well. Scary.

Just to double check: Your helpers are signed with the same cert as the main app is, right?

I just got this as well from a user of my app (Find Any File). Attached. This happened when a user wanted to copy an unknown number of file references to the pasteboard. Note that the app memory is around 18 GB. I wonder if the number of copied items is so large that the Mac simply ran out of memory. faf.crash

nevermind

I am disappointed that there is no actual answer to the question in the title. I need an answer to this and this is the first hit on Google. Yet, all that I see here is suggestions for solving the specific issue but not the question in the title. To answer Quinn's question: In my case, I need to keep my code compatible with various SDK versions (for various reasons that are valid but shouldn't need to be justified here), so I need to add conditional code depending on the SDK version. And since it's a compile time issue, I cannot use @available() here, either. So I really need to know which SDK I'm compiling under.

To those who need an answer on how to conditionally compile depending on the used SDK version, here's what I found to work: #if __MAC_OS_X_VERSION_MAX_ALLOWED >= 120000 // ... compiles only when using the macOS12.0 SDK (or later) that comes with Xcode 13.1 #endif

It is important to note that apps with Dock Tile plugins are not allowed in the Mac App Store! So don't waste your time on this if you plan to publish your app only in the MAS.

Just a guess: Since /System/Volumes/Data/ contents are merged into /, you need to replace those paths accordingly (i.e. replace that long prefer in a path with the root path), and then you'll probably get permission. If that works, then I suspect that the Sandbox path access validation code has not been updated to match these aliased paths when volume groups were introduced. I've run into several related issues, outside sandbox, and need to employ similar work-arounds. One would hope that Apple would provide APIs for determining the members and paths of volume groups, and conversion methods, but that's not happening (see also https://stackoverflow.com/q/63876549/43615) Oh, and if you don't like the path replacement method, you could also try getting the CanonicalPath instead - that should also point to the regular path, but take more time than the simple string replacement. If you only do this for a few bookmarks, that shouldn't have an impact and is safer. In fact, there are two ways I use in my apps to get the canonical path. I don't remember which one works, so try them both: Get the fileReferenceURL This code (see also https://stackoverflow.com/questions/64720189): NSString* canonicalFilePath (NSURL *url) { // Caution: Will expand /var/ into /private/var/ NSString *result = nil; if (@available(macOS 10.12, *)) { NSString *cpath; if ([url getResourceValue:&cpath forKey:NSURLCanonicalPathKey error:nil] && cpath) { result = cpath; } else { result = url.URLByResolvingSymlinksInPath.path; } } else { result = [[url fileReferenceURL] filePathURL].path; } return result; }

The Stackoverflow link is https://stackoverflow.com/q/70584180

Still getting these occasionally, including macOS 12.2. I just realize that the aforementioned crashes in 10.8 were actually more than one separate crashes in Finder, see http://www.applephoon.com/Finder-path-bar-makes-finder-crash-thread-75359-1-1.html

Oh hell! It's not my fault, it's Apple's. The signature appears to be outdated, or refences an expired cert. The fix is to temporarily change the system date to before Oct 1, 2019 for the installation.

Alright, I figured out a way to identify the server by contacting it via https and then checking its certificate. That should be pretty reliable. Below the code I use, though I ran into one complication: The mount URL I get for my QNAP NAS is: "QNAS._smb._tcp.local", but that is not a valid host name I can use in a NSURLRequest! I need to transform that into the actual host name, which is "QNAS.local". Since the former is a Bonjour related name, and when I browse the Bonjour registry with BonJeff, I can find the mapping, this seems to be an overly complicated method. I wonder what the proper way is to get the basic host name from such a service name. I've googled for a while but could not find anything about it. For now, I simply remove all components from the host name that start with an underscore, but I'm not sure if that's a safe method. #import <NetFS/NetFS.h> #import <Security/Security.h> #import "AppDelegate.h" @interface AppDelegate () <NSURLSessionDelegate> @end @implementation AppDelegate - (void)applicationDidFinishLaunching:(NSNotification *)aNotification { CFURLRef furl = CFURLCreateWithFileSystemPath(NULL, CFSTR("/Volumes/TheNAS"), kCFURLPOSIXPathStyle, true); NSURL *url = CFBridgingRelease(NetFSCopyURLForRemountingVolume (furl)); NSArray *parts = [[url.host componentsSeparatedByString:@"."] filteredArrayUsingPredicate:[NSPredicate predicateWithBlock:^BOOL(NSString* _Nullable part, id _Nullable bindings) { return ![part hasPrefix:@"_"]; }]]; NSString *addr = [parts componentsJoinedByString:@"."]; NSLog(@"host: %@ -> %@", url.host, addr); NSMutableURLRequest *request = [[NSMutableURLRequest alloc] init]; [request setURL:[NSURL URLWithString:[NSString stringWithFormat:@"https://%@", addr]]]; NSURLSession *session = [NSURLSession sessionWithConfiguration:[NSURLSessionConfiguration defaultSessionConfiguration] delegate:self delegateQueue:nil]; [[session dataTaskWithRequest:request completionHandler:^(NSData *data, NSURLResponse *response, NSError *error) { NSLog(@"Done."); [NSApp terminate:self]; }] resume]; } -(void)URLSession:(NSURLSession *)session didReceiveChallenge:(NSURLAuthenticationChallenge *)challenge completionHandler:(void (^)(NSURLSessionAuthChallengeDisposition, NSURLCredential * _Nullable))completionHandler { SecTrustRef trustRef = [[challenge protectionSpace] serverTrust]; SecCertificateRef certRef = SecTrustGetCertificateAtIndex(trustRef, 0); CFStringRef name = nil; SecCertificateCopyCommonName(certRef, &name); NSLog(@"name: %@", name); // reject the challenge because we have all we wanted completionHandler (NSURLSessionAuthChallengeCancelAuthenticationChallenge, nil); } @end

@eskimo, With the code from SRVResolver I can indeed resolve QNAS._smb._tcp.local. Problem is: If the host name is a plain one, like syno.local, then I get neither an error nor a callback. And using a Timeout for a local-only NS resolve seems wrong to me. How should I best handle this? Is there a way to tell when I need to use the SRV record resolver?

I found the solution myself by trial-and-error: The NSURL resource key NSURLVolumeNameKey contains the original name. It's not clearly documented that it does, but in my tests that did return the desired result.